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REMARKS 

The Office Action objects to Applicants original specification because the specification 
contains an embedded hyperlink. As will be shown below, the example URL included in 
Applicants' original specification is not intended to be active and is used to meet the 
enablement requirements of 35 U.S.C. § 1 12, first paragraph. The example URL is 
therefore in compliance with MPEP § 608.01 and Applicants respectfully request 
reconsideration of Applicants' original specification. 

The Office Action takes the position that the title of the present application is not 
descriptive. As will be shown below, the title of the present application is short and as 
specific as possible. The title of present application is therefore in compliance with the 
rule governing titles, 37 C.F.R. § 1.72 and Applicants respectfully request reconsideration 
of the title of the present application. 

Claims 15-21 stand rejected under 35 U.S.C. § 101 for reciting unpatentable subject 
matter. As will be shown below, neither the computer product claims of the present 
application nor any other language in the present application makes any attempt 
whatsoever to claim or enable any intangible embodiment of a recording medium. As 
such, the rejections of claims 15-21 should be withdrawn. 

Claims 1-21 stand rejected under 35 U.S.C.§ 102(e) as being anticipated by Barker, et al. 
(U.S. Patent No. 7,191,404) (hereafter 'Barker'). As will be shown below, Barker does 
not anticipate controlling a GUI display for a plug-in as claimed in the present 
application. Claims 1-21 are therefore patentable and should be allowed. Applicants 
respectfully traverse each rejection individually below and request reconsideration of 
claims 1-21. 
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Remarks Regarding Embedded Hyperlinks 



The Office Action at page 2, states: 



The disclosure is objected to because it contains an embedded hyperlink 
and/or other form of browser-executable code. See page 10, lines 29-30. 
Applicant is required to delete the embedded hyperlink and/or other form 
of browser-executable code. 

That is, the Office Action takes the position that page 10, lines 29-30 of Applicants' 
original specification contains an embedded hyperlink or browser-executable code. 
Applicants respectfully submit in response, however, that what Applicants' original 
specification at page 10, lines 29-30, in fact discloses is: 



Exemplary ways of publishing XML syntax for representing XML GUI 
objects include XML Document Type Definitions ("DTDs") and XML 
schema. Such a DTD or schema may be published by storing the DTD or 
schema at a location in cyberspace, such as, for example, a location 
identified by a URL such as: http://www.gui.obj/guiObjects/syntax.dtd. 

That is, what Applicants' original specification at page 10, lines 29-30, actually discloses 
is an example uniform resource locator ('URL') identifying a published XML document 
type definition ('DTD'). Applicants submit that the example URL at page 10, lines 29-30 
of Applicants' original specification is in compliance with the rule governing embedded 
hyperlinks, MPEP §608.01, which states: 



Where the hyperlinks and/or other forms of browser-executable codes 
themselves rather than the contents of the site to which the hyperlinks are 
directed are part of applicant's invention and it is necessary to have them 
included in the patent application in order to comply with the requirements 
of 35 U.S.C. 112, first paragraph, and applicant does not intend to have 
these hyperlinks be active links, examiners should not object to these 
hyperlinks. The Office will disable these hyperlinks when preparing the 
text to be loaded onto the USPTO web database. 

The example URL included in Applicants' original specification is not intended to be an 
active link, but only an example of URL identifying a XML DTD - enablement under 35 
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U.S.C. § 1 12 for publishing XML syntax as claimed in the present application. That is, 
the example URL is included to meet the enablement requirements of 35 U.S.C. § 1 12, 
first paragraph by describing at least one exemplary way of publishing XML syntax for 
representing XML GUI objects - as claimed here. Because the example URL included in 
Applicants' original specification is not intended to be an active link, but is only intended 
to enable at least one way of publishing XML syntax for representing XML GUI objects 
as claimed, the use of this example URL in the present application is not prohibited by 
MPEP § 608.01. Applicants therefore respectfully request reconsideration of the 
objection to Applicants original specification. 

Remarks Regarding The Title Of The Present Application 

The Office Action at page 2, states: 

The title of the invention is not descriptive. A new title is required that is 
clearly indicative of the invention to which the claims are directed. 

That is, the Office Action takes the position that the title of present application is not 
descriptive. Applicants respectfully submit in response, that the title of the present 
application, "Controlling a GUI Display for a Plug-in," is in compliance with the rule 
governing titles, 37 C.F.R. § 1.72(a), which states that "the title of the invention may not 
exceed 500 characters in length and must be as short and specific as possible." The title 
of present application is less than 500 characters, only 40 characters including spaces, 
and the title is short, only seven words. "Controlling a GUI Display for a Plug-in" is 
specific to and descriptive of the methods, systems, and computer program products for 
controlling a GUI display for a plug-in in an application supporting plug-ins as claimed 
and described in the present application. Applicants therefore respectfully submit that the 
title of the present application satisfies the requirements of 37 C.F.R. § 1.72 and request 
reconsideration of the objection to the title. 
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Claim Rejections - 35 U.S.C. § 101 



Claims 15-21 stand rejected under 35 U.S.C. § 101 for reciting unpatentable subject 
matter. The Office Action takes the position that Applicants original specification at 
page 4, lines 17-28 describes a 'recording medium,' recited in claim 15, as including both 
tangible and intangible embodiments. The Office Action lists several example 
embodiments of an intangible recording medium including "transmission media, radio 
frequency (RF), infrared (IR), a carrier wave, telephone line, a signal, etc." Applicants 
respectfully submit in response, however, that what Applicants' original specification at 
page 4, lines 17-28, in fact states is: 



The invention also may be embodied in a computer program product, such 
as a diskette or other recording medium, for use with any suitable data 
processing system. Embodiments of a computer program product may be 
implemented by use of any recording medium for machine-readable 
information, including magnetic media, optical media, transmission 
media, or other suitable media. Persons skilled in the art will immediately 
recognize that any computer system having suitable programming means 
will be capable of executing the steps of the method of the invention as 
embodied in a program product. Persons skilled in the art will recognize 
immediately that, although most of the exemplary embodiments described 
in this specification are oriented to software installed and executing on 
computer hardware, nevertheless, alternative embodiments implemented 
as firmware or as hardware are well within the scope of the present 
invention. 

This excerpt from Applicants' specification represents an enablement for computer 
program product claims under In re Beauregard, 53 F. 3d 1583 (Fed. Cir. 1995). The 
computer program product claims in the present application are claims 15-21. Neither 
the computer product claims nor the above cited excerpt of Applicants original 
specification nor any other language in the present application makes any attempt 
whatsoever to claim or enable any intangible embodiment of a recording medium. 



In addition to the fact that Applicants do not claim or enable an intangible recording 
medium there is another reason that the rejections under 35 U.S.C. § 101 should be 
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withdrawn: None of the example embodiments suggested by the Office Action are 
intangible. The term 'intangible' is a term used to describe a non-physical object. The 
Merriam- Webster Dictionary defines the word 'physical' as: 

1 a: of or relating to natural science b (1): of or relating to physics (2): 
characterized or produced by the forces and operations of physics 

2 a: having material existence: perceptible especially through the senses 
and subject to the laws of nature 

That is, an object is physical if the object is subject to the laws of nature. Each of the 
Office Action's examples, "transmission media, radio frequency (RF), infrared (IR), a 
carrier wave, telephone line, a signal, etc.," is clearly an object that is subject to the laws 
of nature. Consider, for example, the Office Action's example of a telephone line. 
Telephone lines are entirely physical, often comprising wires and plastic. In addition, 
telephone lines are subject to laws of nature - the matter comprising a telephone line can 
neither be created nor destroyed, the telephone line cannot defy the law of gravity, and so 
on. In a similar manner each of the examples provided by the Office Action is a physical 
object, subject to the laws of nature. It cannot be said then that any of the example 
embodiments suggested by the examiner are in any way non-physical or intangible. For 
these reasons claims 15-21 recite an entirely physical computer program product which 
Applicants are entitled to claim pursuant to In re Beauregard, 53F.3dl583 (Fed. Cir. 
1995). The rejection of claims 15-21 under 35 U.S.C. § 101 should therefore be 
withdrawn and the claims should be allowed. Applicants respectfully request 
reconsideration of claims 15-21. 

Claim Rejections - 35 U.S.C. § 102 Over Barker 

Claims 1-21 stand rejected under 35 U.S.C.§ 102(e) as being anticipated by Barker. To 
anticipate claims 1-21 under 35 U.S.C. § 102(e), Barker must disclose each and every 
element and limitation recited in the claims of the present application. As explained 
below, Barker does not disclose each and every element and limitation recited in the 
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claims of the present application and therefore does not anticipate the claims of the 
present application. 

Barker Does Not Disclose Each and Every Element 
Of The Claims Of The Present Application 

"A claim is anticipated only if each and every element as set forth in the claim is found, 
either expressly or inherently described, in a single prior art reference." Verdegaal Bros, 
v. Union Oil Co. of California, 814 F.2d 628, 631, 2 USPQ2d 1051, 1053 (Fed. Cir. 
1987). As explained in more detail below, Barker does not disclose each and every 
element of claim 1, and Barker therefore cannot be said to anticipate the claims of the 
present application within the meaning of 35 U.S.C. § 102(e). 

Independent claim 1 recites: 

1 . A method for controlling a GUI display for a plug-in in an application 
supporting plug-ins, the method comprising: 

receiving, at run time, in the application from the plug-in a request to 
display a GUI object, wherein the application has standards of appearance 
for the GUI display; 

responsive to the request, retrieving an XML representation of the GUI 
object that complies with the application's standards of appearance for the 
GUI display; and 

displaying the GUI object in dependence upon the retrieved XML 
representation of the GUI object. 
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Barker Does Not Disclose Responsive To 
The Request, Retrieving An XML Representation Of The 
GUI Object That Complies With The Application's 
Standards Of Appearance For The GUI Display 

The Office Action takes the position that Barker at column 5, lines 38-47, discloses the 
second element of claim 1 : responsive to the request, retrieving an XML representation 
of the GUI object that complies with the application's standards of appearance for the 
GUI display. Applicants respectfully note in response, however, that what Barker at 
column 5, lines 38-47, in fact discloses is: 



Management definition object 220. such as a MOF, is read and evaluated 
(step 215) to determine the panels, plug-in code, and NLS data needed to 
process. A graphical user interface is generated to support the model 
(predefined process 225, see FIGS. 8 and 9 for further processing details). 
The generated user interface panels are stored in panel files data store 230. 
In one embodiment, the panel files are created as Java and/or Extensible 
Markup Language (XML) files capable of being rendered with browser 
software such as Microsoft Internet Explorer. TM. or Netscape 
Navigator.TM. 

That is, Barker at column 5, lines 38-47, discloses a graphical user interface that is 
generated to support the model. Barker's graphical user interface that is generated to 
support the model does not disclose responsive to the request, retrieving an XML 
representation of the GUI object that complies with the application's standards of 
appearance for the GUI display as claimed in the present application because Barker's 
GUI display is generated as a single GUI display for use by many management consoles. 
In contrast, however, the GUI object as claimed in the present application is displayed in 
dependence upon the retrieved XML representation of the GUI object and the XML 
representation of the GUI object complies with a single application's standards of 
appearance for a GUI display. That is, the display of GUI objects as claimed here is 
application specific - a GUI object for a first application is displayed in dependence upon 
the standards of appearance for the first application while the same GUI object for a 
second application is displayed in dependence upon the second application's standards of 
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appearance. Barker's GUI display, however is not application specific, it is generated 
once for use by many management consoles. Barker at column 3, lines 1-14, states: 

A management definition object (i.e., management model) is evaluated. 
The result of the evaluation is the generation of graphical user interface 
(GUI) display panels that support the management model. The panels are 
created in a console neutral manner so that the same panels are displayed 
from a variety of management consoles. An algorithm transforms the 
management model into a format suitable to be displayed via a graphical 
user interface independent of any specific console interface requirements. 
In this manner, customers can select a preferred management console from 
a variety of management consoles and product providers can create 
management definition objects and corresponding display panels without 
generating specific display panels for each of the available management 
consoles. 

That is, Barker's GUI display panel is 'console neutral,' and independent of any specific 
console interface requirements, so that the same GUI display could be used on a variety 
of management consoles. Because Barker's GUI display panel is 'console neutral' and 
independent of any specific console interface requirements, Barker teaches directly away 
from retrieving an XML representation of the GUI object that complies with a particular 
application's standards of appearance for the GUI display and displaying the GUI object 
in dependence upon the retrieved XML representation of the GUI object. In fact, Barker 
does not disclose at this reference point, or any other reference point, any application 
specific GUI display, but only a 'console neutral' GUI display panel that is used by many 
management consoles. Because Barker's 'console neutral' GUI display panel does not 
disclose a GUI object as claimed in the present application, Barker cannot disclose 
responsive to the request, retrieving an XML representation of the GUI object that 
complies with the application's standards of appearance for the GUI display as claimed 
here. Because Barker does not disclose each and every element and limitation of 
Applicants' claims, Barker does not anticipate Applicants' claims, and the rejections 
under 35 U.S.C. § 102(e) should be withdrawn. 
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Barker Does Not Disclose Receiving, At Run Time, 
In The Application From The Plug-In A Request To 
Display A GUI Object, Wherein The Application Has 
Standards Of Appearance For The GUI Display 

The Office Action takes the position that Barker at column 5, lines 15-31, discloses the 
first element of claim 1 : receiving, at run time, in the application from the plug-in a 
request to display a GUI object, wherein the application has standards of appearance for 
the GUI display. Applicants respectfully note in response, however, that what Barker at 
column 5, lines 15-31, in fact discloses is: 



Executing the setup program included with the product allows the 
customer to select from one or more available consoles (step 170). The 
number of consoles the customer selects depends upon (i) the number of 
consoles for which the software manufacturer enabled the product to 
interface (defined by product properties 110 and console plug-in data 
120), and (ii) the number of consoles that the customer uses or plans to 
use. For example, if the software manufacturer enabled the product to be 
used with four consoles, those four consoles would be selectable by the 
customer. If the customer has a particular console of choice, such as the 
Tivoli console, then he selects his preferred console and does not install 
plug-in files associated with the other consoles. The selected console plug- 
in(s) are installed on the customer's computer system (step 1 80, see FIG. 6 
for further customer installation details). The installed plug-in components 
are registered with the applicable consoles (step 190) so mat the consoles 
recognize the installed plug-in components and the installed product when 
used by the customer. 

That is, Barker at column 5, lines 15-31, discloses a product that installs a plug-in where 
the setup program included with the product allows the customer to select from one or 
more available consoles. Barker's product that installs a plug-in where the setup program 
included with the product allows the customer to select from one or more available 
consoles, does not disclose receiving, at run time, in the application from the plug-in a 
request to display a GUI object, wherein the application has standards of appearance for 
the GUI display as claimed in the present application. Barker does not disclose a GUI 
object as claimed in the present application. GUI objects as claimed here are displayed 
on an application specific basis. Barker however only discloses a GUI display panel that 
is 'console neutral' and independent of any specific console interface requirements, so 
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that the same GUI display can be used on a variety of management consoles. Because 
Barker does not disclose a GUI object as claimed in the present application, Barker 
cannot disclose receiving, at run time, in the application from the plug-in a request to 
display a GUI object, wherein the application has standards of appearance for the GUI 
display. Because Barker does not disclose each and every element and limitation of 
Applicants' claims, Barker does not anticipate Applicants' claims, and the rejections 
under 35 U.S.C. § 102(e) should be withdrawn. 

Barker Does Not Disclose Displaying The 
GUI Object In Dependence Upon The Retrieved 
XML Representation Of The GUI Object 

The Office Action takes the position that Barker at column 7, lines 53-65, discloses the 
third element of claim 1 : displaying the GUI object in dependence upon the retrieved 
XML representation of the GUI object. Applicants respectfully note in response, 
however, that what Barker at column 7, lines 53-65, in fact discloses is: 



In addition, object properties also include qualifiers that are used to group 
one or more data elements. Other object properties may specify valid data 
types and values that correspond with one or more data elements, as well 
as list items that are used to allow the user to select from a list of valid 
values. These qualifiers, data element names, and data element attributes 
are used to display GUI panels from a management console allowing a 
user to view and manipulate values associated with the product (see FIG. 9 
for an example GUI panel). Examples of properties include caption, 
description, node name, states (e.g., started, stopped), modes (e.g., Start 
Mode), and the names of parameters to a particular method. Property 
names are usually designated by designers of the CIM model, rather than 
being fixed or predetermined. 

That is, Barker at column 7, lines 53-56, discloses qualifiers, data element names, and 
data element attributes that are used to display GUI panels from a management console. 
Barker's qualifiers, data element names, and data element attributes that are used to 
display GUI panels from a management console do not disclose displaying the GUI 
object in dependence upon the retrieved XML representation of the GUI object, as 
claimed in the present application. Barker does not disclose a GUI object as claimed in 
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the present application. GUI objects as claimed here are displayed on an application 
specific basis. Barker however only discloses a GUI display panel that is 'console 
neutral' and independent of any specific console interface requirements, so that the same 
GUI display can be used on a variety of management consoles. Because Barker does not 
disclose a GUI object as claimed in the present application, Barker cannot disclose 
displaying the GUI object in dependence upon the retrieved XML representation of the 
GUI object as claimed in the present application. Because Barker does not disclose each 
and every element and limitation of Applicants' claims, Barker does not anticipate 
Applicants' claims, and the rejections under 35 U.S.C. § 102(e) should be withdrawn. 

Relations Among Claims 

Independent claims 8 and 15 are system and computer program product claims for 
controlling a GUI display for a plug-in in an application supporting plug-ins 
corresponding to independent method claim 1 that include "means for" and "means, 
recorded on [a] recording medium, for" controlling a GUI display for a plug-in in an 
application supporting plug-ins. For the same reason that Barker does not disclose a 
method for controlling a GUI display for a plug-in in an application supporting plug-ins, 
Barker also does not disclose systems and computer program products for controlling a 
GUI display for a plug-in in an application supporting plug-ins corresponding to 
independent claims 8 and 15. Independent claims 8 and 15 are therefore patentable and 
should be allowed. 

Claims 2-7, 9-14, and 16-21 depend respectively from independent claims 1,8, and 15. 
Each dependent claim includes all of the limitations of the independent claim from which 
it depends. Because Barker does not disclose each and every element of the independent 
claims, Barker does not disclose each and every element of the dependent claims of the 
present application. As such, claims 2-7, 9-14, and 16-21 are also patentable and should 
be allowed. 
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Remarks Regarding Dependent Claims 2-7, 9-14, And 16-21 



In addition to the fact that Barker, as explained above, does not disclose any of the 
elements of the independent claims in the present application, Barker also does not 
disclose any of the elements of dependent claims 2-7, 9-14, and 16-21. Consider claim 3 
as an example of a dependent claim having elements that Barker does not disclose. The 
Office Action relies on Barker at column 6, lines 25-40 as disclosing the following 
limitations of claim 3: ". . .providing through the application for the plug-in access to a 
subset of a set of GUI objects supported by a GUI environment." What Barker at column 
6, lines 25-40 actually discloses is a "process of creating console plug in files" where "the 
mapping model in the management definition object (MOF) is transformed to generate 
GUI panels." Barker's process of creating console plug in files and generating GUI 
panels does not disclose providing access to a subset of a set of GUI objects supported by 
a GUI environment as recited in dependent claim 3. In similar manner Barker does not 
disclose the limitations of dependent claims 2-7, 9-14, and 16-21, including: 



Claim 2: installing the plug-in in the application, including 
configuring the application with the location of at least one 
XML representation of at least one GUI object. 

Claim 4: providing GUI functions for the plug-in through a GUI API 
in the application, wherein receiving, at run time, in the 
application from the plug-in a request for display of a GUI 
object further comprises receiving a GUI API call from the 
plug-in. 

Claim 5: receiving from the plug-in a request to retrieve user input 
responsive to the GUI object; and returning to the plug-in 
responsive user input. 

Claim 6: parsing the retrieved representation of the GUI object, 
wherein displaying the GUI object further comprises 
displaying the GUI object in dependence upon the parsed 
representation of the GUI object. 

Claim 7: publishing XML syntax for representing XML GUI objects 
operable by a plug-in through the application. 
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For these reasons, Barker does not disclose anticipate claims 2-7, 9-14, and 16-21 and the 
rejections under 35 U.S.C. § 102 should be withdrawn. 

Conclusion 

Claims 1-21 stand rejected under 35 U.S.C. § 102 as being anticipated by Barker. Barker 
does not disclose each and every element of Applicants' claims. Barker therefore does 
not anticipate Applicants' claims. Claims 1-21 are therefore patentable and should be 
allowed. Applicants respectfully request reconsideration of claims 1-21. 

The Office Action objects to Applicants original specification because the specification 
contains an embedded hyperlink. The example URL included in Applicants' original 
specification is in compliance with MPEP § 608.01 . Applicants therefore respectfully 
request reconsideration of Applicants' original specification. 

The Office Action takes the position that the title of the present application is not 
descriptive. The title of the present application is short and as specific as possible. The 
title of the present application is therefore is in compliance with the rule governing titles, 
37 C.F.R. § 1.72 and Applicants' respectfully request reconsideration of the title of the 
present application. 

Claims 15-21 stand rejected under 35 U.S.C. § 101 for reciting unpatentable subject 
matter. Neither the computer product claims of the present application nor any other 
language in the present application makes any attempt whatsoever to claim or enable any 
intangible embodiment of a recording medium. As such, the rejections of claims 15-21 
should be withdrawn. 



14 



AUS920040011US1 



The Commissioner is hereby authorized to charge or credit Deposit Account No. 09-0447 
for any fees required or overpaid. 



Respectfully submitted, 



Date: July 19, 2007 By: 

Reg. No. 44,537 

Biggers & Ohanian, LLP 

P.O. Box 1469 

Austin, Texas 78767-1469 

Tel. (512) 472-9881 

Fax (5 12) 472-9887 

ATTORNEY FOR APPLICANTS 
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